✨ Fiche d'Aide à la Décision

FAD

-

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

• 1. ANAL

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

• Visiter les sites clients comme les usines, entrepôts et/ou bureaux
• Conduire des ateliers orientés processus.
• Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
• Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
• Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
• Identifier les volumes des référentiels et données transactionnelles
• Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
• Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Versions du document

Liste de diffusion

1. Vue d‘ensemble
   1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

**3.1. Contexte et Hypothèses**

Le processus d'achat du client est composé de trois types d'achats : projets, achats génériques société et achats mutualisés multi-projet. Les besoins projets sont anticipés ou constatés et sont traités au niveau de chaque projet. Le contrôle et la réception de la livraison sont effectués avec photos du colis non ouvert et puis colis ouvert avec les pièces.

La chaîne d'approbation est dépendante du seuil, qui est défini en fonction de la personne qui passe la commande ou du risque sur la commande. Les critères d'approbation incluent l'achat dans le budget ou pas.

Actuellement, le client utilise un système de gestion de stock sans document d'entrée en stock, ce qui pose des difficultés pour le chef de projet. Le client souhaite mettre en place un flux d'approbation formalisé et souhaite intégrer les coûts de transport liés à la commande.

Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système et l'intégration des coûts de transport liés à la commande.

Les hypothèses retenues incluent la nécessité de scanner les documents avec la pièce pour assurer la traçabilité, la prise en compte des différents plannings (fournisseur, transport, spécialité) et la documentation à joindre à la demande de devis.

**INFORMATION MANQUANTE** sur les attentes vis-à-vis du projet et les difficultés rencontrées.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Les commandes doivent être liées à un projet et un numéro de projet est obligatoire sur le devis pour lier la commande au projet.
- La gestion des Incoterms est prise en compte, notamment l'utilisation du champ Shipment Method Code et la précision de la ville lorsqu'un Incoterm est renseigné.
- Le contrôle qualité est effectué après réception et la validation du responsable qualité valide la réception.
- Les lignes budget sont utilisées pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification sont renseignées dans les lignes projet.
- Les pièces VOL sont livrées avec des certificats et les lieux de stockage sont définis, notamment Payerne.
- Le suivi des lead times fournisseurs est effectué et les différents plannings (fournisseur, transport, spécialité) sont pris en compte.

3.4. Documents et statistiques

Planification des achats

La planification des achats est un processus clé dans l'entreprise qui consiste à anticiper et à gérer les besoins en matière d'approvisionnement. Dans l'atelier achats, les besoins sont identifiés en fonction des projets, des besoins hors projets et des besoins spécifiques.

Les besoins projet sont composés de composants ou de licences, tandis que les besoins hors projets concernent l'équipement de bureau. Avant de passer à la commande, un devis est demandé pour valider les coûts et les délais.

La chaîne d'approbation est actuellement verbale, mais l'objectif est de mettre en place un flux d'approbation formalisé. Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système et l'intégration des coûts de transport liés à la commande.

La gestion des incoterms est également importante, car elle permet de définir les conditions de livraison et de paiement. La documentation à joindre à la demande de devis est également essentielle pour valider les coûts et les délais.

La réception des marchandises est détaillée et inclut la quantité, le rattachement à la commande et le contrôle qualité. Le responsable qualité valide la réception et le processus d'inspection est défini avec lui. Les lignes budget sont également importantes pour remonter le coût budgété ou le montant réel dans la commande.

Les informations suivantes sont nécessaires pour planifier les achats :

- Les besoins projet et hors projet
- Les devis et les commandes
- La chaîne d'approbation
- Les fonctionnalités souhaitées dans le système
- La gestion des incoterms
- La documentation à joindre à la demande de devis
- La réception des marchandises
- Le contrôle qualité

[INFORMATION MANQUANTE]

3.5. Volume des données

**Planification**

**3.5. Volume des données**

Le processus de planification implique la gestion des volumes de données liés aux achats. Les données importantes incluent les besoins des projets, les demandes d'offres, les commandes, les livraisons et les réceptions.

**Volume des données**

* Les besoins des projets sont anticipés ou constatés et entraînent des achats spécifiques pour chaque projet.
* Les demandes d'offres sont renseignées avec le numéro de projet pour lier la commande au projet.
* Les commandes sont créées à partir des demandes d'offres et incluent des informations telles que la quantité, le rattachement à la commande et les dates de planification.
* Les livraisons sont suivies avec des photos des colis et des documents de contrôle qualité.
* Les réceptions sont validées par le responsable qualité après inspection et incluent des informations telles que la quantité, le rattachement à la commande et les photos des colis.

**Gestion des données**

* Les données sont stockées dans des tables telles que la fiche article, le journal des achats et le workflow validation.
* Les données sont exportées facilement dans Excel pour une analyse détaillée.
* Les champs tels que le Due Date, la Requested Receipt Date et le Shipment Method Code sont utilisés pour suivre les livraisons et les réceptions.

**Informations manquantes**

* [INFORMATION MANQUANTE] sur les volumes de données spécifiques attendus dans le système.

3.6. Écarts critiques et interfaces

**Écarts critiques et interfaces**

Les besoins projets sont anticipés ou constatés puis acheminés vers un achat au niveau de chaque projet. Les instructions d'incoming sont données par le chef de projet, et les certificats sont gérés par la Qualité Contrôle.

**Écarts critiques :**

* Pas de document d'entrée en stock, ce qui rend difficile le contrôle et la réception de la livraison.
* Pas de suivi de la confirmation de commande fournisseur.
* Pas de date de livraison renseignée dans le système.
* Pas d'intégration des coûts de transport liés à la commande.
* Pas d'inspection systématique à la réception.
* Le Chef de Projet donne l'instruction de faire un contrôle qualité léger ou approfondi, mais il n'y a pas de processus détaillé d'inspection.

**Interfaces nécessaires :**

* Intégration avec les autres applications, services ou départements impactés, tels que la gestion des projets, les Work-Packages et les certificats.
* Interface avec les fournisseurs pour la gestion des coûts, des livraisons et des non-conformités.
* Interface avec la Qualité Contrôle pour la gestion des certificats et des contrôles qualité.
* Interface avec les lieux de stockage pour la gestion des stocks et des livraisons.

**Liste des écarts à suivre et à clôturer :**

* Mise en place d'un flux d'approbation formalisé pour les commandes.
* Création d'un document d'entrée en stock pour le contrôle et la réception de la livraison.
* Suivi de la confirmation de commande fournisseur.
* Date de livraison renseignée dans le système.
* Intégration des coûts de transport liés à la commande.
* Inspection systématique à la réception.
* Définition d'un processus détaillé d'inspection.
* Gestion des certificats et des contrôles qualité.
* Interface avec les fournisseurs pour la gestion des coûts, des livraisons et des non-conformités.
* Interface avec la Qualité Contrôle pour la gestion des certificats et des contrôles qualité.
* Interface avec les lieux de stockage pour la gestion des stocks et des livraisons.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

Traitement d'une livraison directe

Contexte et hypothèses :

Actuellement, le processus de traitement des livraisons directes est complexe et manque de formalisme. Le chef de projet donne l'instruction de faire un contrôle qualité léger ou approfondi sans avoir de document d'entrée en stock, ce qui peut entraîner des difficultés pour le contrôle et la réception de la livraison. Les certificats ne sont pas toujours nécessaires pour toutes les petites commandes.

Hypothèses retenues :

* Le processus de traitement des livraisons directes doit être formalisé et simplifié.
* Le système doit permettre de suivre la confirmation de commande fournisseur, la date de livraison et les coûts de transport liés à la commande.
* Les coûts de transport doivent être intégrés dans le système.
* Les certificats ne sont pas toujours nécessaires pour toutes les petites commandes.
* Le système doit permettre de scanner les documents avec la pièce pour assurer la traçabilité.
* Les lieux de stockage doivent être pris en compte dans le système.
* Le suivi des lead times fournisseurs et des différents plannings (fournisseur, transport, spécialité) doit être possible dans le système.
* Le numéro de projet doit être obligatoire sur le devis pour lier la commande au projet.
* La documentation à joindre à la demande de devis doit être prise en compte dans le système.
* Les champs "Due Date" et "Requested Receipt Date" doivent être utilisés dans le système.
* Le système doit permettre de gérer les Incoterms et de préciser la ville lorsque l'Incoterm est renseigné.
* Le système doit permettre de détailler la partie shipping ultérieurement.
* Les lignes budget doivent permettre de remonter le coût budgété ou le montant réel dans la commande.
* Les dates de planification dans les lignes projet doivent être prises en compte dans le système.

Processus à mettre en place :

* Créer un document d'entrée en stock pour chaque livraison directe.
* Formaliser le processus de contrôle qualité et de réception de la livraison.
* Intégrer les coûts de transport dans le système.
* Permettre de scanner les documents avec la pièce pour assurer la traçabilité.
* Prendre en compte les lieux de stockage dans le système.
* Suivre les lead times fournisseurs et les différents plannings (fournisseur, transport, spécialité) dans le système.
* Obliger le numéro de projet sur le devis pour lier la commande au projet.
* Prendre en compte la documentation à joindre à la demande de devis dans le système.
* Utiliser les champs "Due Date" et "Requested Receipt Date" dans le système.
* Gérer les Incoterms et préciser la ville lorsque l'Incoterm est renseigné.
* Détailler la partie shipping ultérieurement.
* Remonter le coût budgété ou le montant réel dans la commande à l'aide des lignes budget.
* Prendre en compte les dates de planification dans les lignes projet dans le système.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "Warehouse receipt" est créé pour suivre les lots de pièces reçues.
- La qualité doit valider le processus de réception en renseignant les informations nécessaires.
- Les certificats sont gérés par la Qualité Contrôle.
- Les photos des colis reçus sont prises pour assurer la traçabilité.
- Le Chef de Projet donne l'instruction de faire un contrôle qualité léger ou approfondi.
- L'ingénieur ou le CP discute directement avec le fournisseur en cas de non-conformité.
- La facture n'est pas payée tant que la non-conformité n'est pas résolue.
- Les acomptes sont pris en compte pour certains fournisseurs.
- Les pièces VOL sont livrées avec des certificats.
- Le suivi des lead times fournisseurs est effectué.
- Les différents plannings (fournisseur, transport, spécialité) sont pris en compte.
- Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
- La documentation est jointe à la demande de devis.
- Les champs "Due Date" et "Requested Receipt Date" sont utilisés.
- Le devis est lié à la commande.
- La gestion des Incoterms est effectuée en utilisant le champ "Shipment Method Code".
- Le numéro de projet et les tâches projet sont renseignés sur les lignes pour permettre la consommation sur le projet.
- La réception est validée lorsque le responsable qualité valide le document de contrôle qualité.
- Le processus d'inspection est défini avec le responsable qualité.
- Les lignes budget sont utilisées pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification sont renseignées dans les lignes projet.

4.4. Documents et statistiques

**Processus : Traitement d’une livraison directe**

**Documents et statistiques**

Dans le cadre d’une livraison directe, les documents ERP suivants sont générés :

- **Fiche article** : mise à jour automatique des quantités en stock après réception des articles.
- **Journal des achats** : enregistrement des commandes passées, des livraisons reçues et des paiements effectués.
- **Workflow validation** : contrôle qualité automatique des articles reçus, avec possibilité de validation ou de non-conformité.
- **Document de contrôle qualité** : création d'un document de contrôle qualité avec rattachement de photos, tracking lot et série.
- **Certificats** : gestion des certificats par la Qualité Contrôle, avec possibilité de scanner les documents avec la pièce pour assurer la traçabilité.

Les états ou statistiques nécessaires au suivi du processus sont :

- **Tableau de bord** : tableau de bord adapté au profil pour l'utilisateur avec les informations pertinentes.
- **Export en Excel** : export facile des données dans Excel pour une analyse détaillée.
- **Statistiques de stock** : suivi des quantités en stock, des commandes passées et des livraisons reçues.
- **Analyse des coûts** : analyse des coûts de transport liés à la commande et des coûts de production.

Ces documents et statistiques permettent de suivre les livraisons directes de manière précise et efficace, en garantissant la traçabilité et la conformité des articles reçus.

4.5. Volume des données

**Traitement d’une livraison directe**

**Volume des données**

- Données référentielles : 3 types d'articles (en stock, non inventory, service), 3 types d'achats (projets, achats génériques société, achats mutualisés multi-projet), 1 type de commande (livraison directe).
- Nombre de documents ou transactions générés par période :
+ Dévis : 1 par commande.
+ Commande : 1 par projet.
+ Livraison : 1 par commande.
+ Contrôle qualité : 1 par série, 1 par lot, 1 par commande.
+ Facture : 1 par commande.
- Données générées par le processus de livraison directe :
+ Photos des colis reçus.
+ Documents de contrôle qualité.
+ Informations de planning (lead-time, stock de sécurité, Minimum Order Quantity).
- Données stockées dans les objets BC :
+ Fiche article.
+ Journal des achats.
+ Workflow validation.
+ Tableau de bord adapté au profil pour l'utilisateur.
- Données exportées dans Excel : informations pertinentes pour l'utilisateur.

4.6. Écarts critiques et interfaces

Traitement d'une livraison directe

Écarts critiques et interfaces

- **Écart 1 :** Manque de document d'entrée en stock. Solution : Créer un document d'entrée en stock pour contrôler et réceptionner les livraisons.
- **Écart 2 :** Difficulté pour le chef de projet à contrôler les livraisons. Solution : Utiliser un workflow de validation pour contrôler les livraisons et les pièces reçues.
- **Écart 3 :** Pas de suivi des certificats. Solution : Gérer les certificats par la qualité contrôle et les intégrer dans le processus de réception.
- **Écart 4 :** Pas de document de contrôle qualité. Solution : Créer un document de contrôle qualité avec rattachement de photos et tracking lot et série.
- **Écart 5 :** Pas d'intégration des coûts de transport lié à la commande. Solution : Intégrer les coûts de transport dans le processus de commande.
- **Écart 6 :** Pas de suivi des lead times fournisseurs. Solution : Suivre les lead times fournisseurs pour planifier les livraisons.
- **Écart 7 :** Pas de prise en compte des différents plannings. Solution : Prendre en compte les différents plannings (fournisseur, transport, etc.) pour planifier les livraisons.
- **Écart 8 :** Manque de documentation à joindre à la demande de devis. Solution : Demander la documentation nécessaire à la demande de devis.
- **Écart 9 :** Pas d'utilisation des champs "Due Date" et "Requested Receipt Date". Solution : Utiliser ces champs pour planifier les livraisons.
- **Écart 10 :** Pas de gestion des Incoterms. Solution : Gérer les Incoterms pour planifier les livraisons.

Interfaces nécessaires :

- **Interface 1 :** Intégration avec le système de gestion de projet pour lier les commandes aux projets.
- **Interface 2 :** Intégration avec le système de gestion de stock pour contrôler les stocks et les livraisons.
- **Interface 3 :** Intégration avec le système de gestion de qualité pour gérer les certificats et les contrôles qualité.
- **Interface 4 :** Intégration avec le système de gestion de transport pour planifier les livraisons et les coûts de transport.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Saisie d'une demande de prix

Le processus de saisie d'une demande de prix est actuellement réalisé de manière manuelle, sans aide de l'ERP. Les utilisateurs doivent renseigner les informations nécessaires dans un formulaire papier, qui est ensuite transmis au responsable achats pour validation. Les difficultés rencontrées par les utilisateurs sont notamment la complexité du processus et la nécessité de renseigner des informations supplémentaires manuellement.

Les attentes exprimées par les utilisateurs sont notamment la mise en place d'un flux d'approbation formalisé, la possibilité de suivre la confirmation de commande fournisseur et la date de livraison, ainsi que l'intégration des coûts de transport liés à la commande.

Les hypothèses identifiées pouvant impacter la mise en œuvre du processus dans l'ERP sont notamment la nécessité de paramétrer les champs "Due Date" et "Requested Receipt Date" pour les commandes, ainsi que la gestion des Incoterms et la création d'un document de contrôle qualité avec rattachement de photos.

Actuellement, le processus de saisie d'une demande de prix n'est pas standardisé et peut varier en fonction du type de commande (article ou prestation). Il est également important de noter que les certificats ne sont pas toujours nécessaires pour toutes les petites commandes.

Il est prévu d'organiser un atelier pour discuter de la stratégie de migration et du processus d'achat du besoin à la facturation. Les fonctionnalités souhaitées dans le système incluent notamment le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système et l'intégration des coûts de transport liés à la commande.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

• 1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

- La demande de prix doit être validée par le responsable des achats avant d'être envoyée aux fournisseurs.
- Le numéro de projet doit être obligatoirement renseigné sur la demande de prix pour lier la commande au projet.
- La documentation à joindre à la demande de prix doit être précisée.
- Le responsable des achats doit renseigner les champs "Due Date" et "Requested Receipt Date" sur la demande de prix.
- La demande de prix doit être liée à la commande.
- Le responsable des achats doit renseigner les Incoterms et préciser la ville sur la demande de prix.
- La demande de prix doit être validée par le responsable des achats avant d'être transformée en commande.
- Le responsable des achats doit renseigner les lignes budget pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification doivent être renseignées dans les lignes projet.
- Le responsable des achats doit créer un document de contrôle qualité avec rattachement de photos et tracking lot et série.
- Le responsable des achats doit valider la réception après que le responsable qualité a validé le document de contrôle qualité.
- Le responsable des achats doit renseigner les champs "Quantité" et "Rattachement à la commande" sur la réception.

5.4. Documents et statistiques

Saisie d'une demande de prix

Lors de la saisie d'une demande de prix, un document appelé "Purchase quote" est généré. Ce document est destiné à être envoyé aux fournisseurs pour obtenir des offres.

Le document "Purchase quote" contient les informations suivantes :

- Numéro de projet
- Description du projet
- Liste des articles nécessaires
- Quantité requise
- Date de livraison souhaitée
- Informations de contact

Le responsable achats renseigne les offres fournisseurs dans le système, en rentrant le numéro de projet pour assurer le lien avec la commande et le projet. Les devis sont ensuite liés à la commande en 1 clic.

Les rapports nécessaires pour le pilotage et le contrôle des demandes de prix incluent :

- Tableau de bord adapté au profil de l'utilisateur avec les informations pertinentes
- Export facile dans Excel
- Liste des suivi des demandes de prix
- Indicateurs de suivi des demandes de prix

En termes d'impression, de visualisation ou d'export, les besoins sont les suivants :

- Imprimer les demandes de prix et les offres fournisseurs
- Visualiser les informations de suivi des demandes de prix dans le tableau de bord
- Exporter les informations de suivi des demandes de prix dans Excel

Il est important de noter que les documents générés dans ce processus incluent également les documents de contrôle qualité, les documents de réception et les documents de facturation.

5.5. Volume des données

**Saisie d'une demande de prix**

La saisie d'une demande de prix est un processus clé dans l'atelier d'achat. Cela commence par la création d'une demande de prix, également appelée "Purchase Quote", dans le système de gestion de l'atelier.

**Étape 1 : Création d'une demande de prix**

Le responsable achats crée une demande de prix en renseignant les informations suivantes :

* Type d'article (en stock, non-inventory ou service)
* Quantité demandée
* Date de livraison souhaitée
* Informations de planning (lead-time, stock de sécurité, etc.)

**Étape 2 : Envoi de la demande de prix au fournisseur**

La demande de prix est ensuite envoyée au fournisseur sélectionné, qui renvoie une offre comprenant les prix et les délais de livraison.

**Étape 3 : Rétrocession de l'offre**

L'offre est ensuite rétrocessionnée dans le système de gestion de l'atelier, où elle est associée au projet correspondant.

**Volume des données**

* **Fiche article** : 3 types d'articles (en stock, non-inventory, service)
* **Journal des achats** : 1 journal par jour
* **Demandes de prix** : 1 demande de prix par projet
* **Offres fournisseurs** : 1 offre par demande de prix
* **Commandes** : 1 commande par projet
* **Réceptions** : 1 réception par commande
* **Contrôle qualité** : 1 document de contrôle qualité par série, lot ou commande

Il n'y a pas d'informations disponibles sur les volumes de données pour les périodes (jour, semaine, mois, année).

5.6. Écarts critiques et interfaces

Saisie d'une demande de prix

Lors de la saisie d'une demande de prix, le processus actuel consiste à rentrer les offres fournisseurs dans la fiche article, en rentrant le numéro de projet pour lier la commande au projet. Les offres peuvent ensuite être transformées en commande en 1 clic.

Les écarts critiques entre le fonctionnement actuel et le fonctionnement cible sont les suivants :

- L'absence de suivi de la confirmation de commande fournisseur.
- La date de livraison n'est pas renseignée dans le système.
- L'intégration des coûts de transport liés à la commande est inexistant.
- Il n'y a pas d'inspection systématique à la réception.
- Chaque colis reçu n'est pas pris en photo.
- Le processus de contrôle qualité n'est pas défini.

Les interfaces nécessaires avec d'autres systèmes ou services sont les suivantes :

- Intégration avec les systèmes de gestion de projet pour lier les commandes aux projets.
- Intégration avec les systèmes de gestion de stock pour suivre les quantités et les dates de livraison.
- Intégration avec les systèmes de facturation pour suivre les paiements et les factures.

Ces éléments doivent être intégrés dans la liste des écarts à suivre jusqu'à la fin de l'analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Saisie d'une commande cadre

Le processus de commande cadre est utilisé pour passer des commandes pour les besoins des projets. Il existe trois types d'achats : les projets, les achats génériques société (licences, ordinateurs...) et les achats mutualisés multi-projet. Les commandes sont passées à partir des besoins des projets, qui peuvent être anticipés ou constatés.

La saisie d'une commande cadre implique plusieurs étapes :

1. La création d'un devis, qui est lié à la commande.
2. La gestion des Incoterms, qui déterminent les conditions de livraison et de paiement.
3. La saisie des informations de livraison, telles que la date de livraison et le numéro de projet.
4. La validation de la commande par le responsable qualité.
5. La réception des marchandises, qui est suivie d'un contrôle qualité.

Les difficultés ou points critiques identifiés dans le processus actuel sont :

* La manque de formalisation de l'approbation des commandes.
* La nécessité de scanner les documents à la réception pour assurer la traçabilité.
* La gestion des certificats pour les pièces VOL.
* La prise en compte des différents plannings (fournisseur, transport, etc.).

Les attentes exprimées par le client sont :

* La mise en place d'un flux d'approbation formalisé.
* L'intégration des coûts de transport liés à la commande.
* La possibilité de suivre la confirmation de commande fournisseur.
* La date de livraison renseignée dans le système.

Les hypothèses susceptibles d'influencer le périmètre ou la compréhension du processus sont :

* La présence d'un système de gestion de stock.
* La gestion des certificats pour les pièces VOL.
* La prise en compte des différents plannings (fournisseur, transport, etc.).

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
- La commande (Make Order) est liée au devis.
- La quantité reçue est rattachée à la commande.
- Le contrôle qualité est effectué après réception, avec création d'un document de contrôle qualité, rattachement de photos, tracking lot et série.
- La validation de la réception est effectuée par le responsable qualité.
- Les lignes budget permettent de remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification sont renseignées dans les lignes projet.
- Le système doit supporter la gestion des coûts de transport liés à la commande.
- Le système doit supporter la prise en compte des différents plannings : planning fournisseur, planning transport, fournisseurs organisés par spécialité.
- Le système doit supporter la gestion des Incoterms, avec utilisation du champ Shipment Method Code et précision de la ville lorsqu'un Incoterm est renseigné.

6.5. Documents et statistiques

Saisie d'une commande cadre

Les documents générés par l'ERP dans ce processus sont :

- Commande cadre fournisseur
- États de suivi
- Fiche article
- Journal des achats
- Workflow validation

Les statistiques ou indicateurs utilisés par le client pour piloter ce processus sont :

- Suivi de la confirmation de commande fournisseur
- Date de livraison renseignée dans le système
- Intégration des coûts de transport lié à la commande
- Gestion des Incoterms
- Utilisation des champs : Due Date, Requested Receipt Date
- Gestion des lignes budget pour remonter le coût budgété ou le montant réel dans la commande
- Dates de planification dans les lignes projet

Le processus de saisie d'une commande cadre implique plusieurs étapes, notamment :

- Création d'un devis lié à la commande
- Gestion des Incoterms
- Utilisation des champs : Due Date, Requested Receipt Date
- Gestion des lignes budget pour remonter le coût budgété ou le montant réel dans la commande
- Dates de planification dans les lignes projet

La validation de la commande est effectuée par le workflow validation, qui prend en compte les critères d'approbation définis dans le système. La commande est ensuite traitée et les documents nécessaires sont générés, tels que la fiche article et le journal des achats.

6.6. Volume des données

Saisie d'une commande cadre

La saisie d'une commande cadre est un processus qui consiste à créer une commande qui sera utilisée pour plusieurs projets. Le processus commence par la création d'un devis qui est ensuite transformé en commande en 1 clic.

Données référentielles utilisées :

- Fiche article
- Journal des achats
- Workflow validation

Nombre estimé de commandes cadres créées par période :

- Jour : [INFORMATION MANQUANTE]
- Semaine : [INFORMATION MANQUANTE]
- Mois : [INFORMATION MANQUANTE]
- Année : [INFORMATION MANQUANTE]

Le processus de saisie d'une commande cadre implique plusieurs étapes, notamment :

- Création d'un devis
- Transformation du devis en commande
- Validation de la commande
- Réception des marchandises
- Contrôle qualité

Les données référentielles utilisées pour ce processus incluent la fiche article, le journal des achats et le workflow validation. Cependant, il n'y a pas d'informations disponibles sur le nombre estimé de commandes cadres créées par période.

6.7. Écarts critiques et interfaces

Saisie d'une commande cadre

- Lors de la saisie d'une commande cadre, les utilisateurs doivent renseigner les informations suivantes :
* Numéro de projet
* Type d'article (en stock, non inventory ou service)
* Quantité commandée
* Date de livraison attendue
* Informations de planning (lead-time, stock de sécurité, Minimum Order Quantity, etc.)
- Le système doit permettre de générer automatiquement un devis en fonction des informations saisies.
- Le devis doit être lié à la commande et doit inclure les informations suivantes :
* Numéro de projet
* Type d'article
* Quantité commandée
* Date de livraison attendue
* Informations de planning
- Le système doit permettre de gérer les Incoterms et de prendre en compte les différents plannings (fournisseur, transport, etc.).
- La commande doit être rattachée à la commande et doit inclure les informations suivantes :
* Quantité
* Rattachement à la commande
- Le système doit permettre de gérer les contrôles qualité et de créer un document de contrôle qualité avec rattachement de photos et tracking lot et série.

Écarts critiques et interfaces

- Les écarts critiques entre les pratiques actuelles et la cible attendue dans l'ERP sont :
* Pas de document d'entrée en stock
* Difficulté pour le chef de projet de contrôler les pièces reçues
* Pas de suivi de la confirmation de commande fournisseur
* Date de livraison non renseignée dans le système
* Pas d'intégration des coûts de transport lié à la commande
- Les interfaces nécessaires sont :
* Atelier sur la stratégie de migration pour discuter de l'historique
* Processus d'achat – du besoin à la facturation
* Suivi de la confirmation de commande fournisseur
* Date de livraison renseignée dans le système
* Intégration des coûts de transport lié à la commande

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Saisie d'une commande d'achat

Le processus de saisie d'une commande d'achat est initié par la création d'un besoin projet, qui peut être anticipé ou constaté. Le besoin est ensuite transmis à l'atelier achats, qui évalue les besoins et détermine les pièces nécessaires. Le processus est divisé en trois types d'achats : projets, achats génériques société et achats mutualisés multi-projet.

La saisie de la commande est réalisée à l'aide de la fonctionnalité "Purchase quote" (demande d'offre), qui permet de rentrer les offres fournisseurs et de les lier au projet. L'offre peut ensuite être transformée en commande en 1 clic. La gestion de l'incoterm est également prise en compte pour avoir un suivi des dates d'expédition.

La commande est ensuite soumise à une chaîne d'approbation, qui dépend du seuil défini en fonction de la personne qui passe la commande ou du risque sur la commande. Le critère d'approbation est l'achat dans le budget ou pas.

Actuellement, le processus de réception est réalisé manuellement, ce qui peut entraîner des difficultés pour le chef de projet. La création d'un document de réception avec rattachement de photos et tracking lot et série est souhaitée. La validation de la réception est effectuée par le responsable qualité.

Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, l'intégration des coûts de transport liés à la commande et la prise en compte des différents plannings (fournisseur, transport, etc.).

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

- La commande d'achat ne peut être validée que si le devis est lié à la commande et que le numéro de projet est obligatoirement renseigné.
- Toute pièce reçue doit être scannée avec la pièce pour assurer la traçabilité.
- Les certificats sont obligatoirement joints à la demande de devis pour les pièces VOL.
- La réception est validée par le responsable qualité après création d'un document de contrôle qualité avec rattachement de photos et tracking lot et série.
- Les lignes budget doivent être renseignées pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification dans les lignes projet doivent être renseignées pour permettre la consommation sur le projet.
- La gestion des Incoterms est prise en charge en utilisant le champ Shipment Method Code et en précisant la ville lorsque l'Incoterm est renseigné.
- La commande d'achat génère automatiquement un surplus affecté au stock projet ou général selon la codification en cas de sur-réception.
- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.

7.4. Documents et statistiques

Saisie d'une commande d'achat

La commande d'achat est générée à partir d'une demande d'offre (Purchase quote) envoyée aux fournisseurs. L'utilisateur renseigne les informations suivantes :

- Numéro de projet
- Description de l'article ou de la prestation
- Quantité requise
- Date de livraison souhaitée
- Informations de planning (lead-time, stock de sécurité, Minimum Order Quantity, etc.)

La commande d'achat est ensuite validée par le responsable achats et logistique. Le système génère un numéro de commande et un document de commande (Make Order) qui est envoyé au fournisseur.

Les documents générés ou utilisés dans le processus sont :

- Demande d'offre (Purchase quote)
- Commande d'achat (Make Order)
- Document de contrôle qualité (avec rattachement de photos)
- Lignes budget pour remonter le coût budgété ou le montant réel dans la commande

Les informations clés attendues sont :

- Numéro de projet
- Description de l'article ou de la prestation
- Quantité requise
- Date de livraison souhaitée
- Informations de planning (lead-time, stock de sécurité, Minimum Order Quantity, etc.)

Les états, statistiques ou indicateurs nécessaires pour suivre ou analyser le processus sont :

- Suivi de la confirmation de commande fournisseur
- Date de livraison renseignée dans le système
- Intégration des coûts de transport lié à la commande
- Suivi des lead times fournisseurs
- Prise en compte des différents plannings (planning fournisseur, planning transport, etc.)

7.5. Volume des données

Saisie d'une commande d'achat

La saisie d'une commande d'achat est un processus qui consiste à créer une nouvelle commande d'achat dans le système Microsoft Dynamics 365 Business Central.

Données référentielles utilisées :
- Fiche article : les informations relatives aux articles sont utilisées pour créer la commande d'achat.
- Fournisseur : les informations relatives aux fournisseurs sont utilisées pour créer la commande d'achat.

Nombre moyen de commandes d'achat créées sur une période :
- [INFORMATION MANQUANTE]

Processus :
1. Création d'une demande d'offre (Purchase Quote) pour les besoins projet.
2. Renseignement des informations relatives au projet, au fournisseur et au devis.
3. Approbation de la commande d'achat en fonction du seuil défini.
4. Création d'un document de contrôle qualité pour la réception des articles.
5. Validation de la réception par le responsable qualité.

Volume des données :
- [INFORMATION MANQUANTE]

Dans le système Microsoft Dynamics 365 Business Central, les commandes d'achat sont créées à partir de la demande d'offre (Purchase Quote) et sont liées aux projets et aux fournisseurs. Le processus de saisie d'une commande d'achat est formalisé et inclut la création d'un document de contrôle qualité pour la réception des articles.

7.6. Écarts critiques et interfaces

Identifier les écarts majeurs entre le processus existant et la cible attendue, ainsi que les besoins d'interfaces avec d'autres systèmes ou départements.

- **Saisie d'une commande d'achat** :
- Actuellement, la saisie d'une commande d'achat est réalisée de manière manuelle sans lien direct avec les projets.
- Le système souhaite intégrer les coûts de transport liés à la commande et la date de livraison renseignée dans le système.
- La saisie de la commande doit être liée au projet, avec le numéro de projet obligatoire sur le devis.

- **Workflow de validation** :
- Actuellement, l'approbation est verbale et au feeling.
- L'objectif est de mettre en place un flux d'approbation formalisé.

- **Gestion des certificats** :
- Actuellement, pas de document d'entrée en stock, ce qui peut entraîner des difficultés pour le chef de projet.
- Le système souhaite intégrer la prise en charge des certificats pour les pièces VOL.

- **Intégration avec les projets** :
- Le système souhaite intégrer les coûts de projet et les dates de planification dans les lignes projet.

- **Interface avec les fournisseurs** :
- Le système souhaite intégrer le suivi des lead times fournisseurs et la prise en compte des différents plannings (fournisseur, transport, etc.).

- **Gestion des commandes** :
- Le système souhaite intégrer la gestion des Incoterms et la prise en compte des différents types de commandes (article ou prestation).

- **Contrôle qualité** :
- Le système souhaite intégrer la création d'un document de contrôle qualité avec rattachement de photos et tracking lot et série.

- **Gestion des lignes budget** :
- Le système souhaite intégrer les champs pour remonter le coût budgété ou le montant réel dans la commande.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Saisie d'un retour d'une commande achat

Contexte et Hypothèses

Le processus de gestion des retours fournisseurs est actuellement géré de manière manuelle, sans document d'entrée en stock. Le chef de projet donne l'instruction de contrôler et de réceptionner la livraison, avec photos du colis non ouvert et ouvert avec les pièces. Les instructions d'incoming sont données par le chef de projet. En cas de non-conformité, une NC (Non Conformité) est ouverte et traitée avec le fournisseur, avec éventuel paiement en avance.

Les difficultés rencontrées sont la perte de traçabilité des colis et la difficulté pour le chef de projet de contrôler et de réceptionner les livraisons. Les attentes exprimées par le client sont la mise en place d'un flux d'approbation formalisé, le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, l'intégration des coûts de transport lié à la commande et la prise en compte des différents plannings.

Les hypothèses susceptibles d'avoir un impact sur la définition ou la mise en œuvre du processus sont la qualité des données, l'outillage existant et les dépendances organisationnelles. Il est également important de prendre en compte les différents plannings, tels que le planning fournisseur, le planning transport et les fournisseurs organisés par spécialité.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

8.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "journal des achats" doit être utilisé pour enregistrer les mouvements de stock liés aux retours de commande.
- Le "workflow validation" doit être configuré pour valider les retours de commande avant de les marquer comme "réceptionnés".
- Le "fiche article" doit être mis à jour pour refléter les modifications apportées aux pièces retournées.
- Les "photos des colis" doivent être prises et associées à chaque retour de commande pour assurer la traçabilité.
- Le "contrôle qualité" doit être effectué avant de marquer les pièces comme "réceptionnées".
- Les "certificats" doivent être vérifiés et enregistrés dans le système pour chaque retour de commande.
- Le "suivi des lead times fournisseurs" doit être pris en compte pour planifier les retours de commande.
- Les "plannings" (fournisseur, transport, etc.) doivent être pris en compte pour planifier les retours de commande.
- Le "numéro de projet" doit être obligatoirement renseigné pour chaque retour de commande pour lier la commande au projet.

8.4. Documents et statistiques

Saisie d'un retour d'une commande achat

Lors d'un retour d'une commande achat, plusieurs documents et statistiques sont générés ou exploités dans l'ERP.

**Documents**

* Un document de retour de commande est créé pour enregistrer les informations relatives au retour, notamment le numéro de commande, la quantité à retourner, la raison du retour et la date de retour.
* Un document de réception de retour est créé pour enregistrer les informations relatives à la réception des articles retournés, notamment la quantité reçue, la date de réception et les photos des articles.

**Statistiques**

* Le tableau de bord adapté au profil de l'utilisateur permet de visualiser les informations pertinentes relatives aux retours de commande, notamment le nombre de retours, la quantité retournée et les raisons des retours.
* Les rapports de retour de commande et de réception de retour permettent de suivre les retours de commande et les réceptions de retour en temps réel.

**Workflow validation**

* Un workflow de validation est mis en place pour garantir que les retours de commande et les réceptions de retour soient validés par les responsables concernés avant d'être enregistrés dans l'ERP.

**Journal des achats**

* Le journal des achats est mis à jour pour refléter les retours de commande et les réceptions de retour.

**Fiche article**

* La fiche article est mise à jour pour refléter les quantités retournées et les raisons des retours.

**Rapports**

* Les rapports de retour de commande et de réception de retour permettent de suivre les retours de commande et les réceptions de retour en temps réel.

En résumé, la saisie d'un retour d'une commande achat implique la création de documents et la mise à jour de statistiques et de rapports pour suivre les retours de commande et les réceptions de retour.

8.5. Volume des données

Saisie d'un retour d'une commande achat

Le processus de saisie d'un retour d'une commande achat est décrit comme suit :

- Le chef de projet donne l'instruction de faire un contrôle qualité léger ou approfondi pour chaque colis reçu.
- L'ingénieur ou le chef de projet discute directement avec le fournisseur en cas de non-conformité.
- La facture n'est pas payée tant que la non-conformité n'est pas résolue.
- Certains fournisseurs demandent des acomptes.

En termes de volumes de données, il est mentionné que :

- Les certificats sont gérés par la Qualité Contrôle.
- Les pièces VOL sont livrées avec des certificats.
- Les documents d'entrée en stock sont difficiles à contrôler.
- Il n'y a pas de document d'entrée en stock actuellement.

Il n'est pas précisé si des indicateurs de performance sont utilisés pour suivre les retours de commandes achat.

8.6. Écarts critiques et interfaces

Saisie d'un retour d'une commande achat

Lorsqu'un retour d'une commande achat est effectué, les écarts critiques entre les pratiques actuelles et les pratiques cibles doivent être identifiés. Actuellement, le processus de retour d'une commande achat n'est pas formalisé et dépend de la personne qui passe la commande ou du risque sur la commande. Un seuil est défini pour déclencher la chaîne d'approbation.

Il est souhaité mettre en place un flux d'approbation formalisé pour les retours de commande achat. Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, et l'intégration des coûts de transport liés à la commande.

Dans le système, il est possible de rentrer les offres fournisseurs et de les transformer en commande en 1 clic. La gestion de l'incoterm est également possible pour avoir un suivi des dates d'expédition. Cependant, actuellement, pas de document d'entrée en stock, ce qui peut poser des difficultés pour le chef de projet.

Pour résoudre ces écarts critiques, il est nécessaire de mettre en place un système de gestion des retours de commande achat qui formalise le processus et intègre les fonctionnalités souhaitées. Cela nécessite une intégration avec les autres applications ou départements, notamment la gestion des projets et la qualité contrôle.

Les interfaces nécessaires avec d'autres applications ou départements incluent :

* Gestion des projets
* Qualité contrôle
* Gestion des fournisseurs
* Gestion des transporteurs

Ces éléments doivent être intégrés et suivis dans la liste des écarts à finaliser en fin de phase d'Analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

**9.1. Contexte et Hypothèses**

Le processus de rapports achat vise à fournir des informations claires et précises sur les achats effectués par l'entreprise. Les besoins en analyses sont les suivants :

* Suivi des commandes en cours et des livraisons attendues
* Contrôle des coûts et des délais de livraison
* Gestion des fournisseurs et des incoterms
* Suivi des pièces et des certificats

Les points critiques identifiés sont les suivants :

* La nécessité d'un flux d'approbation formalisé pour les commandes
* La gestion des coûts de transport liés à la commande
* La prise en compte des différents plannings (fournisseur, transport, etc.)
* La nécessité d'un suivi des lead times fournisseurs

Les attentes pour la mise à disposition de rapports ou tableaux de bord sont les suivants :

* Un tableau de bord adapté au profil de l'utilisateur avec les informations pertinentes
* Un export facile dans Excel
* Un suivi en temps réel des commandes et des livraisons

Les hypothèses susceptibles d'influencer la conception du reporting sont les suivantes :

* Disponibilité et qualité des données
* Granularité des données
* Capacité d'export
* Nécessité d'un suivi en temps réel

Il est important de noter que les informations sur la gestion des projets, les Work-Packages et les dates/quantités/budget ne sont pas explicitement mentionnées dans les notes sources. Il est donc impossible de les prendre en compte dans ce contexte.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Les commandes doivent être liées à un projet, avec un numéro de projet obligatoire sur le devis pour lier la commande au projet.
- La documentation à joindre à la demande de devis doit être prise en compte.
- Les champs "Due Date" et "Requested Receipt Date" doivent être utilisés pour planifier la livraison.
- La gestion des Incoterms doit être prise en compte, avec l'utilisation du champ "Shipment Method Code" et la précision de la ville lorsqu'un Incoterm est renseigné.
- La réception doit être validée par le responsable qualité après création d'un document de contrôle qualité avec rattachement de photos, tracking lot et série.
- Les lignes budget doivent être utilisées pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification dans les lignes projet doivent être prises en compte.

9.4. Documents et statistiques

**Documents et statistiques**

Pour assurer un suivi fiable de l'activité achat, les documents suivants sont attendus :

- **Fiche article** : pour chaque article, une fiche doit être créée avec les informations suivantes : description, quantité en stock, prix, fournisseur, etc.
- **Journal des achats** : un journal doit être tenu pour enregistrer les achats effectués, y compris la date, le fournisseur, la quantité, le prix, etc.
- **Workflow validation** : un workflow de validation doit être mis en place pour garantir que les achats sont validés par les autorités compétentes avant d'être effectués.
- **Tableau de bord** : un tableau de bord adapté au profil de l'utilisateur doit être mis en place pour afficher les informations pertinentes relatives aux achats, telles que les commandes en attente, les livraisons à venir, les pièces manquantes, etc.

Les statistiques suivantes doivent être disponibles :

- **Nombre de commandes en attente** : le nombre de commandes en attente de livraison doit être affiché dans le tableau de bord.
- **Quantité de pièces manquantes** : la quantité de pièces manquantes doit être affichée dans le tableau de bord.
- **Prix moyen des achats** : le prix moyen des achats doit être calculé et affiché dans le tableau de bord.
- **Fournisseurs les plus utilisés** : les fournisseurs les plus utilisés doivent être identifiés et affichés dans le tableau de bord.

Ces documents et statistiques permettront de suivre l'activité achat de manière fiable et d'identifier les problèmes potentiels pour les résoudre en temps opportun.

9.5. Volume des données

**Volume des données exploitées dans le cadre du reporting**

Le processus de reporting achat utilise les données suivantes :

* **Historique** : les données historiques sont utilisées pour analyser les tendances et les comportements d'achat.
* **Nombre de lignes de factures ou commandes** : il y a [INFORMATION MANQUANTE] lignes de factures ou commandes enregistrées dans le système.
* **Fiche article** : les données de la fiche article sont utilisées pour déterminer les quantités et les coûts des achats.
* **Journal des achats** : le journal des achats est utilisé pour enregistrer les mouvements d'entrée et de sortie des stocks.
* **Workflow validation** : le workflow validation est utilisé pour approuver les commandes et les factures.
* **Tableau de bord adapté au profil** : le tableau de bord adapté au profil est utilisé pour afficher les informations pertinentes aux utilisateurs.

Les données sont exportées facilement dans Excel pour faciliter l'analyse et la prise de décision.

En outre, les fonctionnalités suivantes sont souhaitées dans le système pour améliorer la gestion des données :

* Suivi de la confirmation de commande fournisseur
* Date de livraison renseignée dans le système
* Intégration des coûts de transport lié à la commande

Ces fonctionnalités aideront à améliorer la précision et la fiabilité des données, ce qui est essentiel pour prendre des décisions éclairées.

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

**10.1. Contexte et Hypothèses**

L'atelier Achats de l'entreprise Almatech gère les achats de composants, licences et équipements de bureau pour les projets et les besoins hors projet. Les achats sont réalisés en fonction des besoins projetés ou constatés, avec un seuil d'approbation dépendant de la personne qui passe la commande ou du risque sur la commande.

Le processus d'achat comprend les étapes suivantes :

* Demande d'achat pour les besoins projetés ou constatés
* Création d'un devis pour les besoins projetés ou constatés
* Approbation du devis par le chef de projet ou la personne responsable
* Passation de la commande en fonction du devis approuvé
* Réception des marchandises et contrôle qualité
* Validation de la réception par le responsable qualité
* Facturation et paiement des marchandises reçues

Les difficultés rencontrées actuellement sont :

* Pas de document d'entrée en stock pour les marchandises reçues
* Difficulté pour le chef de projet pour contrôler les marchandises reçues
* Pas de suivi de la confirmation de commande fournisseur
* Date de livraison non renseignée dans le système
* Pas d'intégration des coûts de transport liés à la commande
* Pas d'inspection systématique à la réception
* Chaque colis reçu est pris en photo mais il n'est pas toujours clair à qui il est destiné

Les hypothèses susceptibles d'avoir un impact sur la reprise ou l'exploitation de l'historique sont :

* La mise en place d'un flux d'approbation formalisé pour les achats
* L'intégration des coûts de transport liés à la commande
* La création d'un document d'entrée en stock pour les marchandises reçues
* Le suivi de la confirmation de commande fournisseur
* La date de livraison renseignée dans le système

Il est important de noter que ces hypothèses nécessitent une analyse plus approfondie pour déterminer leur impact réel sur la reprise ou l'exploitation de l'historique.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "journal des achats" permet de suivre les commandes et les livraisons.
- Le "workflow validation" est utilisé pour valider les pièces et les commandes.
- Les "fiches article" contiennent les informations sur les articles, y compris les références, les quantités et les prix.
- Les "lignes budget" permettent de suivre les coûts budgétés et les montants réels dans les commandes.
- Les "dates de planification" dans les lignes projet permettent de suivre les délais de livraison et les quantités à livrer.
- Le "numéro de projet" est obligatoire sur le devis pour lier la commande au projet.
- La "documentation" à joindre à la demande de devis est utilisée pour valider les commandes.
- Le "contrôle qualité" est effectué à la réception des pièces et permet de valider la qualité des articles.
- Le "tracking lot et série" permet de suivre les pièces et les lots.
- Le "rattachement de photos" permet de valider la qualité des articles.
- Le "responsable qualité" valide la réception des pièces après contrôle qualité.

10.4. Documents et statistiques

**Processus : Historique achat**

**Documents et statistiques**

Pour suivre et analyser l'activité d'achat, il est recommandé de consulter les documents suivants :

* Fiche article : pour vérifier les informations relatives aux articles, tels que les quantités en stock, les prix et les fournisseurs.
* Journal des achats : pour suivre les commandes passées, les livraisons reçues et les paiements effectués.
* Workflow validation : pour suivre les étapes de validation des commandes et des livraisons.
* Tableau de bord adapté au profil pour l'utilisateur : pour visualiser les informations pertinentes relatives à l'activité d'achat.

Les statistiques utiles pour le suivi et l'analyse de l'activité d'achat incluent :

* Nombre de commandes passées et livrées par mois.
* Quantité totale de produits achetés et livrés par mois.
* Montant total des achats par mois.
* Durée moyenne de livraison par mois.
* Taux de conformité des produits livrés par mois.

Il est également recommandé de consulter les informations relatives aux fournisseurs, tels que les lead times, les plannings et les incoterms.

10.5. Volume des données

**Processus : Historique achat**

**Volume des données**

* Période de reprise : [INFORMATION MANQUANTE]
* Nombre estimé de documents : [INFORMATION MANQUANTE]
* Données référentielles associées :
+ Fiches articles : 3 types d'articles (en stock, non inventory, service)
+ Journal des achats : historique des achats, y compris les commandes, les livraisons et les ponctions
+ Workflow validation : processus d'approbation des commandes et des livraisons
* Données à conserver :
+ Historique des commandes et des livraisons
+ Informations de planning (lead-time, stock de sécurité, Minimum Order Quantity, etc.)
+ Données de suivi (quantité, rattachement à la commande, etc.)
* Données à supprimer : [INFORMATION MANQUANTE]

Il est important de noter que les données à conserver et à supprimer dépendront des besoins spécifiques de l'entreprise et des exigences réglementaires. Il est recommandé de consulter les documents internes et les réglementations pertinentes pour déterminer les données à conserver et à supprimer.

10.6. Écarts critiques et interfaces

Identifier les écarts critiques ou interfaces nécessaires autour de la gestion de l’historique d’achat.

- **Contrôle qualité** : pas d’inspection systématique à la réception, mais prise en photo des colis reçus. Le processus d’inspection doit être défini avec le responsable qualité.
- **Rattachement à la commande** : quantité et rattachement à la commande doivent être renseignés lors de la réception.
- **Validation de la réception** : la réception est validée lorsque le responsable qualité valide le document de contrôle qualité.
- **Suivi des coûts** : lignes budget pour remonter le coût budgété ou le montant réel dans la commande.
- **Gestion des Incoterms** : utilisation du champ Shipment Method Code, et précision de la ville lorsqu’un Incoterm est renseigné.
- **Numéro de projet obligatoire** : sur le devis pour lier la commande au projet.
- **Documentation à joindre** : à la demande de devis.
- **Utilisation des champs** : Due Date et Requested Receipt Date.
- **Gestion des certificats** : les certificats doivent être validés par la Qualité Contrôle.
- **Facturation** : facture non payée tant que la non-conformité n’est pas résolue.
- **Acomptes** : certains fournisseurs demandent des acomptes.
- **Traçabilité** : les documents sont scannés avec la pièce pour assurer la traçabilité.
- **Lieux de stockage** : Payerne.
- **Suivi des lead times fournisseurs** : nécessaire.
- **Prise en compte des différents plannings** : planning fournisseur, planning transport, fournisseurs organisés par spécialité.
- **Workflow validation** : nécessaire pour valider la réception et la commande.
- **Journal des achats** : nécessaire pour suivre les achats et les commandes.
- **Fiche article** : nécessaire pour gérer les articles et les commandes.
- **Workflow de commande** : nécessaire pour gérer les commandes et les réceptions.
- **Gestion des projets** : nécessaire pour gérer les projets et les commandes associées.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

Initialisation de la liste d'écarts

La liste d'écarts est initialisée à la fin de la phase d'Analyse. Cette liste sera stockée dans SharePoint.

Contrôle qualité

* Le processus de contrôle qualité n'est pas défini.
* Il n'y a pas de document d'entrée en stock.
* La validation de la réception est effectuée par le responsable qualité.

Gestion des projets

* Les besoins projet sont composés de composants ou de multitude de composants, de licences.
* Les besoins hors projet sont des équipements de bureau.
* Les commandes sont liées à un numéro de projet obligatoire.

Gestion des fournisseurs

* Les fournisseurs sont organisés par spécialité.
* Les lead times fournisseurs sont suivis.
* Les Incoterms sont utilisés pour détailler la partie shipping.

Réception

* La quantité reçue est rattachée à la commande.
* Le contrôle qualité est effectué avec rattachement de photos.
* Le tracking lot et série est effectué.

Document de contrôle qualité

* Un document de contrôle qualité est créé avec rattachement de photos.
* Le tracking lot et série est effectué.
* La réception est validée par le responsable qualité.

Processus d'achat

* Un devis est demandé avant de passer à la commande.
* Les types de commandes sont des articles ou des prestations.
* L'approbation actuelle est verbale, au feeling.
* L'objectif est de mettre en place un flux d'approbation formalisé.

Fonctionnalités souhaitées

* Suivi de la confirmation de commande fournisseur.
* Date de livraison renseignée dans le système.
* Intégration des coûts de transport lié à la commande.
* Pas d'inspection systématique à la réception.
* Chaque colis reçu est pris en photo.
* Lorsqu'un colis arrive, il n'est pas toujours clair à qui il est destiné.
* Le Chef de Projet donne l'instruction de faire un contrôle qualité léger ou approfondi.
* L'ingénieur ou le CP discute directement avec le fournisseur en cas de non-conformité.
* Facture non payée tant que la non-conformité n'est pas résolue.
* Certains fournisseurs demandent des acomptes.
* À la réception, l'atelier scanne les documents avec la pièce pour assurer la traçabilité.
* Toutes les pièces VOL sont livrées avec des certificats.

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).